Electronic Version 
Stylesheet Version vl.1.1 

Description 
WORKFLOW SYSTEM AND METHOD 

Background of Invention 

[0001] The disclosure relates generally to a workflow system and 
method therefor, and more particularly, to a workflow 
system that is triggered by documents delivered by a doc- 
ument notification and delivery service. 

[0002] Generally, there exists an increasing amount of informa- 
tion contained in electronic documents available from nu- 
merous heterogeneous, widely distributed sources. Keep- 
ing up to date with recently published material relevant to 
a particular topic is a challenge. Document Notification 
and Delivery Services (DNDS) aim to facilitate this task by 
providing notification and delivery services for documents 
concerning specified subjects. 

[0003] An example of a document notification and delivery ser- 
vice is Yaka that is described in the following publications 
which are incorporated herein by reference: Damian Ar- 
regui, Francois Pacull, Jutta Willamowski, "Yaka: Document 
Notification and Delivery Across Heterogeneous Document 



Repositories", in Proceedings of CRIWG 2001, Darmstadt, 
Germany, September 6-8, 2001; and European Patent Ap- 
plication EP 1111518 Al, entitled "System And Method For 
Document Notification And Delivery Across Heteroge- 
neous Document Repositories". 

[0004] As described in the publications, Yaka applies a four step 
solution that involves document detection, processing, 
notification, and delivery. More specifically, Yaka detects 
new documents published in each information source. It 
performs a first level of relevance filtering based on the 
document's properties (e.g., keywords, location, type, cor- 
relation with sample documents, etc.). Yaka then pro- 
cesses information by extracting meta-information (e.g. 
summary, language, authors, etc.) from the documents, 
sometimes using complementary linguistic services. Yaka 
subsequently sends notification e-mail containing the 
document meta-information to all interested users (i.e., 
subscribers). Finally, Yaka delivers on demand document 
content to the requesting users by transforming the docu- 
ment into the appropriate format depending on the se- 
lected delivery medium (e.g. e-mail, printer, PDA). 

[0005] The concept of subjects is central to Yaka. Subjects act as 
distribution channels for documents relevant to a particu- 



lar topic. A subject can be seen as a collection of views on 
different information sources. In order to fine-tune the 
subject definitions, Yaka allows filters to be defined on 
top of the information sources. Once a subject is defined, 
users can subscribe to it. When subscribing to a subject 
each user defines subject related preferences. In defining 
a subject related preference, the user also specifies a pre- 
ferred delivery media and a preferred notification and de- 
livery scheme. Then Yaka notifies the user of newly pub- 
lished documents. Upon receipt of a document notifica- 
tion, the user can request document delivery. 
[0006] | n addition, there exist document-centered workflow 

management systems (WFMS) for defining, managing, and 
executing workflow processes containing sets of interre- 
lated tasks, which produce and consume documents. The 
WFMS handles and distributes these documents to users, 
assigned to complete tasks associated with the docu- 
ments, according to a predefined process description. U.S. 
Patent Nos. 6,493,731 and 6,505,219, which are incorpo- 
rated herein by reference, are examples of a WFMS in 
which process descriptions describe the flow of work and 
responsibility of tasks defining a process description. A 
task is completed when the person responsible for the 



task prepares a task document. The process description 
completes when the final task in the process description is 
completed. 

[0007] The aforementioned systems, however, are not integrated 
and do not readily allow flexibility of design. For example, 
they do not allow exceptions of a workflow system to be 
easily managed. Accordingly, it would be desirable to pro- 
vide a system that solves these and other problems. 
Summary of Invention 

[0008] | n accordance with the invention, a document manage- 
ment and delivery service (DNDS) is coupled to one or 
more document-centered workflow management systems 
to allow users more flexibility in defining workflow pro- 
cesses. Generally, the document notification and delivery 
service is used to trigger a workflow process. The work- 
flow process in turn produces documents that the docu- 
ment management and delivery service detects and dis- 
tributes to other, independently operating, workflow pro- 
cesses. The document notification and delivery service 
provides flexible document distribution channels that fa- 
cilitate the circulation of documents between indepen- 
dently operating workflow processes that take as input 
and produce as output documents. 



[0009] | n accordance with one aspect of the invention, a docu- 
ment management system includes one or more docu- 
ment repositories for storing documents. In addition, a 
document notification and delivery service (DNDS) detects 
documents pertaining to subjects that are stored in the 
document repositories. A plurality of workflow modules 
subscribe to the DNDS to receive documents identified 
that pertain to one or more subscribed subjects. At least 
two workflow modules produce one or more documents 
that are published to one or more of the document repos- 
itories. Further, a first workflow module publishes to one 
of the document repositories a first document which is 
detected by the DNDS and which pertains to at least one 
subscribed subject of a second workflow module. Subse- 
quent to the publication of the first document by the 
DNDS to the one of the document repositories, the DNDS 
delivers the first document to the second workflow mod- 
ule that operates independent from the first workflow 
module to produce a second document. 

[0010] Advantageously, by integrating DNDS and WFMS, indepen- 
dently operating workflow management systems may be 
interconnected without their requiring any knowledge 
about the other. In addition, a workflow management sys- 



tern may be advantageously used with a DNDS to recover 
should the delivery of documents or notifications by the 
DNDS fail. Also, exception handling is simplified because 
the described embodiments couple workflow modules that 
are not aware of each other. Further advantages may be 
realized because workflow modules can be readily added 
and removed from the overall system; for example, 
changes to processes performed by the different workflow 
modules may be readily combined into a single workflow 
module or segmented into several workflow modules 
without affecting other workflow modules in the overall 
system. 

Brief Description of Drawings 

[0011] These and other aspects of the invention will become ap- 
parent from the following description read in conjunction 
with the accompanying drawings wherein the same refer- 
ence numerals have been applied to like parts and in 
which: 

[0012] Figure 1 illustrates an operating environment for perform- 
ing exemplary embodiments of the present invention; 

[0013] Figure 2 illustrates a flow diagram detailing the general 

operation of the workflow management system and docu- 
ment notification and delivery service shown in Figure 1; 



and 

[0014] Figure 3 illustrates one embodiment of the DNDS shown 

in Figure 1. 
Detailed Description 

[001 5] a Operating Environment 

[0016] Figure 1 illustrates an operating environment of a docu- 
ment management system 100 for performing exemplary 
embodiments of the present invention. The operating en- 
vironment includes one or more document repositories 
102, one or more document notification and delivery ser- 
vices (DNDS) 104, one or more notification targets 106, 
and two or more workflow management systems (WFMS) 
108. The notification targets include subscribers 107. 

[0017] The document repositories 102 are electronically man- 
aged on a document server and may be populated or pub- 
lished to by external documents at 124 or by WFMS 108 at 
122. Documents populating the repositories 102 may be 
electronically generated documents 110. Alternatively, 
documents populating the repositories 102 may be elec- 
tronic documents converted from a hardcopy document 
112 recorded at for example scanner 115. Also, docu- 
ments populating the repositories 102 may be identified 



from an electronic tag 118 on a hardcopy document 114 
stored in a hardcopy repository 113, which tag 118 may 
be identified by an electronic tag reader 116. Documents 
identified with an electronic tag 118 may in addition be 
scanned at scanner 115. 

[0018] Hardcopy documents scanned at scanner 115 are in one 
embodiment processed using optical character recogni- 
tion, as available in FlowPort offered by Xerox Corporation 
or PaperPort offered by ScanSoft Inc., to identify textual or 
structural content in bitmapped image data. The elec- 
tronic tag 118 contains an identifier that permits the doc- 
ument repository 102A to know the properties of a hard- 
copy document 114A including the file location 113A at 
which it is stored. A system for identifying and tracking 
tagged documents is described in U.S. Patent Nos. incor- 
porated herein by reference: 6,542,083; 6,340,931; 
6,422,474; 6,342,830; 6,573,916; 6,446,208. 

[0019] Figure 2 illustrates a flow diagram detailing the general 

operation of the workflow management system and docu- 
ment notification and delivery service 104 shown in Figure 
1. At 202, the notification targets 106 and WFMS 108 
subscribe to subjects of the DNDS 104. The DNDS, subse- 
quently at 204 (also shown in Figure 1 at 120), detects 



documents concerning subjects subscribed to at 202 that 
have been published to repositories 102 assigned to be 
watched. In one embodiment, the repositories 102 are as- 
signed to be watched by the notification targets 106 and 
the WFMS 108 that may be published to by WFMS 108 at 
122 or by users external to the document management 
system 100 at 124. 
[0020] if no documents are detected concerning the subscribed 
subjects at 204, then the DNDS 104 repeats the detection 
process after some period of delay. However, if at 204 
documents are detected concerning the subscribed sub- 
jects, then at 206 the DNDS alerts notification targets 106 
(shown in Figure 1 at 126) and delivers to the WFMS 108 
the identified documents that pertain to the subscribed 
subjects (shown in Figure 1 at 128). Each WFMS 108 pro- 
cesses documents delivered by the DNDS 104 in accor- 
dance with the process description of its workflow, and 
upon completing the workflow, the WFMS 108 at 208 
publishes the output of the workflow in the form of a doc- 
ument to one of the repositories 102 (shown in Figure 1 at 
122). 

[0021] Figure 3 illustrates one embodiment of the DNDS 104 
shown in Figure 1 that operates in accordance with the 



exemplary embodiments of the present invention. The 
DNDS 104 includes an information filter 302 for monitor- 
ing and filtering information retrieved from document 
repositories 102 identified in repository directory 304 to 
identify document attributes derived from its content or 
its electronic tag 118. The identified attributes are cate- 
gorized by document attribute subject categorizer 306 
using subject directory 308. The subject directory 308 is 
composed of directories, and any number of subdirecto- 
ries thereof, that further refine subjects (e.g., a subject 
may be divided into sub-classifications of the subject). 
[0022] The workflow management systems 108 and notification 
targets 106 define profiles that are stored in profile/ 
subscription directory 312 through user profiler 320. Each 
profile recorded in the profile/subscription directory 312 
allows users to specify subjects and repositories of inter- 
est, for receiving either documents or notification of iden- 
tified documents matching specified subjects. As part of 
the profile, users may specify preferred and alternate de- 
livery methods (e.g., an identified email address or 
printer) or document formats or processing to be applied 
before delivery (e.g., translation, summarization, enrich- 
ment). In addition, subjects and directories specified by 



users are recorded in the subject directory 308 and the 
repository directory 304, respectively. 
[0023] Documents in the repositories 102 identified as having at- 
tributes that match subjects subscribed to by either the 
workflow management systems 108 or notification targets 
106, are either distributed to workflow management sys- 
tems 108 by document delivery service module 316 or 
notified thereof by subscription delivery service 318, re- 
spectively. As part of document delivery performed by the 
document delivery module 316, transformation to alter- 
nate document formats or analysis thereof (e.g., morpho- 
logical analysis, and part-of-speech disambiguation) may 
be performed by document transformer 322 before deliv- 
ery. 

[0024] £ Independent Workflow Modularization 

[0025] Referring again to Figure 1, aspects of the exemplary em- 
bodiments are described in this section relating to inde- 
pendent workflow modularization. As shown in Figure 1, 
each WFMS in the set of two or more workflow manage- 
ment systems or workflow modules 108 are adapted to 
operate independently. That is, no interaction is required 
between, for example, workflow module 108A and work- 
flow module 108B in order for the document management 



system 100 to operate property. The workflow modules 
108 may consist of workflows carried out in any number 
of different forms such as a web service or a physical pro- 
cess. 

[0026] Advantageously, the document management system 100 
provides a modular system in which different workflow 
management systems (e.g., workflow module 108A) can 
be substituted, replaced, or removed from the set of two 
or more workflow management systems 108 without af- 
fecting the performance or operation of the document 
management system 100. As a further advantage, the 
modular system enables any one of the plurality of work- 
flow management systems 108 to be driven by input from 
any of the plurality of workflow management systems 
108. 

[0027] For example, the WFMS 108A may produce as output 

electronic document HOB that is published to document 
repository 102B (as indicated at 130A) and the workflow 
module WFMS 108C may have subscribed to a subject of 
interest to the DNDS 104 that pertains to the published 
document HOB. The DNDS 104 may subsequently identify 
the published document HOB (as indicated at 130B) and 
deliver the published document HOB in the specified pro- 



file and format to WFMS 108C (as indicated at 130C). 
Upon receipt of the document HOB, the WFMS 108C can 
be triggered (either automatically, manually through user 
intervention, or a combination of both) to initiate a work- 
flow process description to produce, for example, output 
hardcopy document 114B. 

[0028] Alternatively, the DNDS 104 could identify and deliver a 
notification message of the document HOB to a sub- 
scriber such as subscriber 107A. In this alternate embodi- 
ment, the notified subscriber could initiate one more of 
the workflow management system 108 by requesting de- 
livery (with possibly format or analysis performed thereto 
before delivery) of the document identified in the notifica- 
tion message thereto or by manually starting the workflow 
management system with or without the document HOB. 

[0029] More generally, the document management system 100 
allows documents to be published to the document 
repositories (or information sources) 102 that are moni- 
tored by the DNDS 104. In addition, documents produced 
by the workflow management systems 108 are published 
to the document repositories 102 that are monitored by 
the DNDS 104. The DNDS 104 detects documents of in- 
terest published to the repositories 102, through either 



distribution channel, and distributes to subscribed work- 
flow management systems 108 or notifies subscribed no- 
tification targets 106 of published documents the DNDS 
identifies with attributes that align with selected subjects. 

[0030] q Illustrative Examples 

[0031] By way 0 f a fj rs t example consider a large organization 
that has geographically distributed locations, with each 
location having its own well-established hiring process 
(that can be defined as a workflow). The locations cooper- 
ate with each other by sharing information about inter- 
ested candidates they do not decide to hire because of 
lack of need. The process is initiated by the DNDS 104 by 
identifying and delivering to each resource department 
subscribed for document notifications related to resumes 
(i.e., CVs) posted on public document repositories 102A. 
These CVs are reviewed by the subscribers 107 of the hu- 
man resource department to filter out and select CVs of 
interest. Those CVs of interest are published to a propri- 
etary document repository 102B that is either subscribed 
to by location hiring workflows or by subscribers 107. 

[0032] | n addition, notification targets (e.g., human resource, 
managers, etc.) and location hiring processes (i.e., loca- 
tion WFMS) subscribe to the DNDS 104 for information 



relevant to their needs published to the proprietary docu- 
ment repository 102B. Documents of interest identified by 
the DNDS 104 are distributed to subscribed notification 
targets 106 or hiring WFMS 108. Once a hiring workflow is 
initiated by the delivery of a CV or other document (e.g., 
CV review), the WFMS 108 begins processing the CV 
through each stage of the WFMS's process description, 
during which an evaluation document is produced as out- 
put upon completing the process description unless ter- 
minated by an exception during the process. The output 
document is stored in the proprietary document reposi- 
tory 102B, thereby allowing access thereto to interested 
subscribers through identification and notification by the 
DNDS 104 for initiating an additional WFMS 108. 
[0033] By way of a second example, the DNDS 104 and the WFMS 
108 can be used to form a technology watch initiative. Re- 
viewers of different technologies subscribe to subjects 
watched by the DNDS 104. Whenever a technology re- 
viewer receives news about a technology, the technology 
reviewer initiates an instance of a workflow of WFMS 108 
that concerns technology evaluation. The workflow con- 
cerned with technology evaluation initiated by the tech- 
nology reviewer includes an organization of experts that 



review and produce a technology report. Once the tech- 
nology report is complete, it is published to a document 
repository 102 that is monitored by the DNDS 104. Thus, 
users can subscribe to the DNDS for one published report 
104, instead of having to watch and evaluate different 
publications concerning technologies watched by the 
technology reviewers. 

[0034] By way of a third example, the DNDS 104 and the WFMS 
108 can be used to form a invention disclosure submis- 
sion and patent procurement system. In this embodiment, 
invention disclosures 124 are published to a document 
repository 102A. Invention disclosure submissions may 
take the form of electronic submissions 110A or hardcopy 
submissions 112Aor 114A. Such submissions are pub- 
lished to the document repository 102A. Hardcopy inven- 
tion disclosures submissions may be scanned using scan- 
ner 115A and recorded in the document repository 102A. 
Alternatively, hardcopy invention disclosures may be 
tagged with an electronic tag 118A with properties that 
may be read by tag reader 116A. 

[0035] The hardcopy submissions may be filed in an appropriate 
hardcopy repository 113A corresponding to newly sub- 
mitted invention disclosures. The tag reader 116A may 



read the tag 118A on the hardcopy document 114A and 
identify that the document 114A has been submitted and 
a reference thereto or a scanned copy or placeholder 
therefor is stored in the document repository 102A. Si- 
multaneous with filing the hardcopy document 114A in 
the hardcopy repository 113A, or at some point thereafter 
by satisfying a scan placeholder, the paper submission 
114A may be scanned using scanner 115A. Scan place- 
holders are further described in U.S. Patent Applications 
Serial Nos. 10/202,043, entitled "Electronic Filing System 
With File-Placeholders" and 10/202,027 entitled "Elec- 
tronic Filing System With Scan-Placeholders", which are 
both incorporated herein by reference. 
[0036] After submission of invention disclosures, the DNDS 104 
detects new submissions in the document repository 
102A. Depending on the subject matter of the invention 
disclosure, they are delivered to different WFMS 108 that 
are responsible for evaluating their technical merit. Upon 
review, a "technical" report in the form of a document 
published workflow document 122 (in any of the forms 
similar to invention disclosures, e.g., HOB, 112B, or 
114B) to a document repository 102B. The publication of 
these technical reports are detected by the DNDS 104 and 



delivered depending on their subject matter to different 
WFMS 108 (as illustrated by the path defined by 130A, 
130B, and 130C) that are responsible for assessing the 
overall strategic fit of the invention disclosure to deter- 
mine the most appropriate action to take (e.g., whether to 
file a patent application, keep it as a trade secret, do 
nothing, or publish it). These WFMS 108 publish an "over- 
all" report in the form of a document 122 to the document 
repository 102B that corresponds to the action decided 
upon. 

[0037] The DNDS 104 subsequently detects the published overall 
reports in the document repository and delivers, depend- 
ing on their subject matter, to WFMS 108 responsible for 
carrying out the action decided upon for the particular in- 
vention disclosure. For example, depending on the subject 
matter of the invention disclosure, it may be assigned to a 
WFMS 108A responsible for preparing and filing patent 
applications relating to a specific class of technology. 
Once a patent filing takes place, the WFMS 108A can be 
driven by documents 124 received from patent offices and 
published to the repository 102A. In addition, during the 
process interested parties such as inventors and man- 
agers can be defined as notification targets 106 and 



alerted when events are about to occur or have occurred, 
such as when a patent is published, allowed, or issued. 

[0038] d Identifying Highly Rated Documents For Cross-Subject Distribu- 
tion 

[0039] Referring again to Figure 3, aspects of the exemplary em- 
bodiments are described in this section relating to the 
distribution of documents across pre-defined subjects 
once they are given very high ratings for their subject 
matter in their assigned or classified subject category by 
categorizer 306. These identified highly rated documents 
are evaluated by subject rating module 314 using pre- 
selected system and usage parameters to determine if the 
documents should be disseminated across pre-defined 
subjects and subscribed users. Generally, the module 314 
monitors information concerning detected documents for 
which notification or delivery have been performed by 
modules 316 and 318, and uses the monitored informa- 
tion to identify ones of the detected documents as highly 
rated documents for notification to users not originally 
subscribed to the subject for which the notification or de- 
livery was performed. 

[0040] | n operation, the subject rating module 314 monitors and 
records different kinds of application-specific system and 



usage parameters (possibly in any combination of real- 
time, batch mode, and parallel) of operations performed 
by other elements of the DNDS 104. For example, the 
subject rating module 314 monitors events (e.g., deletion, 
modification, notification and/or delivery) and attributes 
(e.g., changes to metadata) of detected documents. Some 
events and attributes are detected using the information 
filter 302 that monitors document: timestamp data, meta- 
data, and source location. Other events and attributes are 
detected using the document delivery service module 316 
and the subscription delivery service module 318 that in- 
clude monitoring: timestamp information concerning the 
delivery and/or notification, the subject through which a 
document has been published and/or notified, the identi- 
fier of the document, the source of the document, the 
type and number of users to which the delivery and/or 
notification is directed, and the delivery medium of the 
document delivery and/or notification (e.g., printer, email, 
file server). Yet other events and attributes are detected 
using information concerning new collections of docu- 
ments created on repositories of a monitored information 
source, such as, when the collection was detected, an 
identifier for the collection, and a parent collection identi- 



fier. 

[0041] | t w j|| b e appreciated by those skilled in the art that many 
additional events and attributes may be monitored by the 
subject rating module 314 to determine whether a docu- 
ment should be given a high rating and considered candi- 
dates for large-scale dissemination across boundaries of 
pre-defined subjects and subscribed users to those sub- 
jects. For example, the monitored information can be 
used to define different criteria thresholds. For instance, 
documents provided in notification alerts 126 can be as- 
signed high ratings if the documents have been requested 
for delivery by a large number of users or at least a mini- 
mum number of specifically identified users (e.g., that are 
recognized as experts in a community). 

[0042] Documents that are detected as having a high rating and 
thereby meriting distribution across boundaries of pre- 
defined subjects and subscribed users may be dissemi- 
nated through different notification targets 106 such as: 
(a) subscribed users; (b) subscribed collaborative filtering 
and recommender systems (e.g., Knowledge Pump devel- 
oped by Xerox Corporation); (c) subscribed intelligent 
mediums (e.g., coversheets produced by Smart Printers 
developed by Xerox Corporation); and (d) public displays 



(e.g., Community Wall developed by Xerox Corporation). 
[0043] | n one alternate embodiment, a specific notification target 
106 (or customized distribution channel subject) is dedi- 
cated to disseminating documents which have been iden- 
tified as having cross-subject boundary value to users. 
When notifying users registered to be notified for this 
customized distribution channel, the original subjects 
through which the document was distributed or published 
are provided, in addition to, other information concerning 
the document for which the notification or delivery is tak- 
ing place. The cross-subject boundary category may be 
customized as any other subject category in accordance 
with user preferences and needs. 

[0044] £ Subject And User Profile Refinement 

[0045] Referring again to Figure 3, aspects of the exemplary em- 
bodiments are described in this section relating to subject 
refinement performed by subject/profile refinement mod- 
ule 310 to improve the accuracy of documents catego- 
rized by categorizer 306. As described in this section, the 
DNDS 104 uses the subject/profile refinement module 
3 10 to improve the efficiency and quality of document de- 
livery and notification. 

[0046] in operation similar to the subject rating module 314, the 



subject/profile refinement module 310 monitors and 
records system and usage parameters (possibly in any 
combination of real-time, batch mode, and parallel) of 
operations performed by other elements of the DNDS 104. 
Also similar to the subject rating module 314, the sub- 
ject/profile refinement module may compute as a usage 
parameter the ratio of the number of document delivery 
request to the total number of document notifications for 
a subject. A high value for the ratio may indicate that 
users tend to be interested in the documents that they 
have been notified of while a low value for the ratio may 
indicate the subject definition is too broad and has not 
found its target audience. 

[0047] Subject refinement is carried out by the subject/profile 
refinement module 310 to more accurately identify and 
timely distribute relevant information for the notification 
target 106 and/or WFMS 108. Once an initial hierarchy of 
subjects in the subject directory 308 is defined for exam- 
ple manually or using a pre-existing hierarchy, the sub- 
ject/profile refinement module 310 uses the monitored 
and recorded system usage parameters to trim, suppress, 
create, or expand a subject in the subject directory 308. 

[0048] a given subject may be trimmed (i.e., removed or sus- 



pended) from the directory 308 if the number of docu- 
ments requested by the users from an information source 
within the given subject drops under a given threshold. A 
given subject may be suppressed from the directory 308 if 
low activity is detected for a subject, either because no 
new documents are detected in the given subject or be- 
cause the ratio of delivery to notification is low for docu- 
ments in that subject. 

[0049] N ew subjects or sub-classes of subjects may be created if 
several clusters with high activity are detected. For exam- 
ple, a cluster of users requesting documents from a clus- 
ter of sources within a single subject or a group of sub- 
jects. In the event such a cluster is identified, a new sub- 
ject associated with the cluster of sources is defined and 
every user associated with the cluster are invited to sub- 
scribe to the new subject. 

[0050] | n addition to creating new subjects, existing subjects can 
be expended with additional sub-categories. That is, new 
collections of documents that are identified within infor- 
mation sources that are related to an existing subject can 
be added as a sub-category of the subject. In one embod- 
iment, keyword matching is performed on a pre-defined 
collection of documents to identify the new collections. 



[0051] Subjects that are refined may require consensus of a sys- 
tem administrator and/or subscribed users to the refined 
subjects. Since subjects are lightweight virtual channels 
that link users to information sources, one embodiment 
retains subjects that have been trimmed or suppressed to 
provide backward subject compatibility, thereby allowing 
users to use either an existing hierarchy or an evolving hi- 
erarchy. 

[0052] | n addition to subject refinement described in the prior 
section, the subject/profile refinement module 310 re- 
fines user profiles in the profile/subscription directory 
312. In one embodiment, delivery/notification, subscrip- 
tion, and viewing preferences of a user profile are modi- 
fied to improve user interaction with the DNDS 104 
through continuous refinement. Similar to subject refine- 
ment, the decision to modify the preferences of a user 
profile may or may not require input from the user corre- 
sponding to the user profile that is being refined. 

[0053] | n 0 ne embodiment, the delivery/notification mode of a 

user (as for example defined in a user profile) is automat- 
ically refined or proposed to a user by module 310. Modi- 
fications are made according to: (a) the frequency that a 
user requests delivery of documents in response to docu- 



ment notifications sent concerning each subscribed sub- 
ject, and (b) the frequency that a user switches between 
"notification and delivery" and "direct delivery" based on, 
for example, the recurrence of the subject category of the 
documents concerned. 

[0054] Additional modifications to delivery and notification may 
be suggested to users depending on specified parameters 
such as delivery frequency/quantity to switch between 
frequency of deliveries (e.g., weekly, monthly, etc.) or 
quantity for each delivery (e.g., per document, n-bundled 
documents, etc.). Alternatively, the system may suggest 
that a user unsubscribe or change the frequency of deliv- 
ery when document delivery requests for document notifi- 
cations fall below a predefined threshold level. 

[0055] | n addition adjustments to a user's notification and deliv- 
ery profile, a profile setting forth a user's preferred man- 
ner of viewing subject categories of documents may be 
personalized with customized views for subscribed sub- 
jects. For example, some subjects may be viewed accord- 
ing to an existing hierarchy or an evolving hierarchy. Ac- 
cordingly, the DNDS 104 may provide users with the abil- 
ity to view hierarchical refinements made to the subject 
directory without requiring a user to accept the refine- 



merits. 

[0056] p Notice Or Document Delivery Failure Recovery 

[0057] Referring again to Figures 1 and 3, aspects of the exem- 
plary embodiments are described in this section relating 
to recovery performed by the failure recovery module 320 
in the event of failure of document delivery or notification. 
By monitoring system and usage parameters, the failure 
recovery module 320 assists in performing failure recov- 
ery. Similar to the subject rating module 314 and the sub- 
ject/profile refinement module 310, the failure recovery 
module 320 monitors and records system and usage pa- 
rameters of operations performed by other elements of 
the DNDS 104. In addition, the failure recovery module 
320 monitors and records system and usage parameters 
of detected component failures (e.g., failure of compo- 
nent, time when failure was first detected, and time when 
component was last accessed). 

[0058] The DNDS 104 is intended to be deployed across a wide- 
area network, such as, the Internet or intranets on which 
different types of failures may occur, such as, network 
partition and host failures. The failure recovery module 
320 helps the DNDS 104 adapt to and correct identified 
failures to preserve as much as possible the functionality 



of the DNDS 104. The solution identified by the failure re- 
covery module 320 will depend on the selected delivery 
media and the affected document repository 102. 
[0059] | n one embodiment, the inability to extract meaningful re- 
sults by the information filter 302 when examining docu- 
ments or web pages at the document repositories 102 is 
detected by the failure recovery module 320. Generally, 
the failure recovery module 320 detects problems with 
wrappers that automatically retrieve information from an 
information source. To detect errors, the failure recovery 
module 320 calculates and records the average number of 
new and modified document for each information source 
identified by the information filer 320 at predefined peri- 
ods of time. In the event the measured value differs sig- 
nificantly from one period to the next, then the failure re- 
covery module 320 notifies concerned users or system 
administrators. 

[0060] in the event the failure recovery module 320 detects a de- 
livery medium is no longer available, then document de- 
livery service module 316 and the subscription service 
module 318 can either wait for replacement or repair the 
delivery medium or deliver the document or notification to 
a different delivery medium or a replacement delivery 



medium. For example, delivery of a document or notifica- 
tion to a faulty printer may be replaced by another printer 
located proximate to the faulty printer or replaced with 
another medium such as email or archival in a document 
repository. Alternatively, the document delivery service 
module 316 and the subscription service module 318 can 
deliver their failed notifications or deliveries to WFMS 109, 
which will manage the recovery process as a workflow 
(either as a module exterior to or integrated in the DNDS 
104). 

[0061] a recovery strategy can be predefined in the profile direc- 
tory 312 for each user that defines alternative delivery 
mediums ordered by preference in the event of the failure 
of preferred delivery medium. Alternatively upon a de- 
tected failure, the failure recovery module 320 may pro- 
pose a list of alternatively available delivery media. In any 
embodiment, the failure recovery module 320 has some 
delay (either implicit through computational delays or ex- 
plicit using an associated system delay for a preset period 
of time) once the problem is identified during which re- 
placement or repair of the delivery medium may have oc- 
curred and in which case alternative recovery actions are 
not required. In any embodiment, the failure recovery 



module 320 keeps users informed of identified failures by 
email or an alternative communication channel. 

[0062] | n addition, reliability profiles of document repositories 
(and information sources) 102 can be defined using 
recorded component failure information associated with 
document repositories or information sources. Depending 
on the frequency and duration of failures of document 
repositories or information sources that are observed by 
the failure recovery module, the repositories or sources 
can be classified as having one of a predefined number of 
operating behaviors (e.g., very reliable, reliable, unreli- 
able, and very unreliable). The classification of a failed 
repository or source is used to dynamically adapt to fail- 
ures and determine appropriate action to take in response 
to identified failures. For example, a source identified as 
being very reliable may cause the failure recovery module 
320 to wait for a predefined period of time before reat- 
tempting to communicate with the repository or source 
and taking alternative action. 

[0063] q Miscellaneous 

[0064] using the foregoing specification, the exemplary embodi- 
ments may be implemented as a machine (or system), 
process (or method), or article of manufacture by using 



standard programming and/or engineering techniques to 
produce programming software, firmware, hardware, or 
any combination thereof. 

[0065] Any resulting program(s), having computer-readable pro- 
gram code, may be embodied within one or more com- 
puter-usable media such as memory devices or transmit- 
ting devices, thereby making a computer program product 
or article of manufacture according to the exemplary em- 
bodiments. As such, the terms "article of manufacture" 
and "computer program product" as used herein are in- 
tended to encompass a computer program existent 
(permanently, temporarily, or transitorily) on any com- 
puter-usable medium such as on any memory device or in 
any transmitting device. 

[0066] Executing program code directly from one medium, stor- 
ing program code onto a medium, copying the code from 
one medium to another medium, transmitting the code 
using a transmitting device, or other equivalent acts may 
involve the use of a memory or transmitting device which 
only embodies program code transitorily as a preliminary 
or final step in making, using, or selling the exemplary 
embodiments. 

[0067] Memory devices include, but are not limited to, fixed 



(hard) disk drives, floppy disks (or diskettes), optical 
disks, magnetic tape, semiconductor memories such as 
RAM, ROM, Proms, etc. Transmitting devices include, but 
are not limited to, the Internet, intranets, electronic bul- 
letin board and message/note exchanges, telephone/mo- 
dem based network communication, hard-wired/cabled 
communication network, cellular communication, radio 
wave communication, satellite communication, and other 
stationary or mobile network systems/communication 
links. 

[0068] a machine embodying the exemplary embodiments may 
involve one or more processing systems including, but not 
limited to, CPU, memory/storage devices, communication 
links, communication/transmitting devices, servers, I/O 
devices, or any subcomponents or individual parts of one 
or more processing systems, including software, firmware, 
hardware, or any combination or subcombination thereof, 
which embody the exemplary embodiments as set forth in 
the claims. 

[0069] while particular embodiments have been described, alter- 
natives, modifications, variations, improvements, and 
substantial equivalents that are or may be presently un- 
foreseen may arise to applicants or others skilled in the 



art. Accordingly, the following appended claims as filed 
and as they may be amended are intended to embrace all 
such alternatives, modifications variations, improvements, 
and substantial equivalents. 



